home *** CD-ROM | disk | FTP | other *** search
/ Freaks Macintosh Archive / Freaks Macintosh Archive.bin / Freaks Macintosh Archives / Textfiles / zines / Phrack / Phrack Issue 52.sit / Phrack52 / 52 / P52-01 next >
Text File  |  1998-01-26  |  12KB  |  216 lines
  1. ---[  Phrack Magazine   Volume 8, Issue 52 January 26, 1998, article 01 of 20
  2.  
  3.  
  4. -------------------------[  P H R A C K     5 2     I N D E X
  5.  
  6.  
  7. --------[  Choose your own $PATH adventure
  8.  
  9.  
  10.  
  11.     Whew.  You would be quite surprised at the evil wheels I had to set in
  12. motion in order to get this issue out.  According to Newton, a Phrack Issue
  13. remains at rest or continues to move in a straight line with a uniform
  14. velocity if there is no unbalanced force acting on it.  This issue was at rest.
  15. Its velocity was constant.  And there were few forces acting on it.  Anyhow,
  16. after many machinations it's here.  Enjoy.
  17.  
  18.     I have a gripe.  Something upon which I'd like dwell for a spell.  Let's
  19. talk about coding aesthetic (from the C programming standpoint).  Now, this is
  20. not a harangue about effective coding or efficient coding, I'll save those for
  21. some other time (perhaps for the time when I feel I can write effective and
  22. efficient code proficiently enough to vituperate to those who do not).  I
  23. want to touch down on a few topics of visual appeal, which are overlooked so
  24. often.
  25.  
  26.     The five major areas I will cover are indentation, brace placement,
  27. use of whitespace, commenting, as well as variable and function nomenclature.
  28. I suppose I should also mention that coding style is a personal preference
  29. type of thing.  There are all kinds of schools of thought out there, and all
  30. kinds of methodologies on how to write pretty code.  In the grand scheme of
  31. things, none are really any more correct than any others, except mine.
  32.  
  33.     C is, for the most part, a format free programming language.  Code can be
  34. written with all manner of whitespace, tabs, and newlines.  The compiler
  35. certainly doesn't care.  The machine doesn't care.  This can be a double
  36. edged sword.  There is quite a bit of room for artistic interpretation.  And
  37. just like in real life, there is a lot of crappy art out there.
  38.  
  39.     Indenting your code is a must.  Please, do this.  Indentation is here for
  40. one simple reason: to clearly and unequivocally define blocks of control.
  41. However, 8 space tabstops are overkill.  Unless you are using a 2 point font on
  42. a 13" screen, 4 spaces should easily define your control blocks.  This allows
  43. you to maintain clarity on an 80 column screen while nesting blocks of control
  44. much deeper then you would with 8 space tab stops.  2 space tabstop advocates
  45. should be shot.  However, don't let typography take over your code (ala ink
  46. obscuring the intent).  If you have 7 million levels of indentation, perhaps
  47. you should rethink your approach to tackling the problem...
  48.  
  49.     Bracing has a simple solution.  The most effective use of bracing is in
  50. placing them on newlines so that they neatly enclose the area of control.  This
  51. is especially important with nested levels of control.  I know this generates
  52. empty lines.  Oh well.  They're free.  Blocks of control become easily visible
  53. and it is easy to isolate one from another.  This goes for functions as well
  54. as conditionals and loop structures.  I know I go against K&R here.  Oh well.
  55.  
  56.     In the pursuit of clear, readable code, whitespace is your friend.  Single
  57. space all keywords and all variables and constants separated by commas.  It's
  58. a simple thing to do to drastically improve readability.  When you have a
  59. series of assignments, one after another, it's a nice touch to line them up on
  60. the closest relative 4 space boundary.  And please, no spaces between structure
  61. pointer operators and structure contents.
  62.  
  63.     Commenting is a delicate matter.  Descriptive, concise, well written code
  64. shouldn't really need commenting, or at least very much of it.  But this isn't
  65. a rant about descriptive, concise, well written code.  If you feel the need
  66. to comment your code, follow a few simple rules:
  67.     - Keep the comment block as small as possible.
  68.     - Don't tab out your comment frames to line up with each other.  That's
  69.       just plain fucking annoying.  If you're doing that, you have too many
  70.       comments anyway.
  71.     - Commenting datatype declarations rather then the functions that
  72.       manipulate them is usually more helpful.
  73.     - If you must comment, keep your style as consistent as possible.  If the
  74.       commenting detracts from the readibilty of your code, you've just ponied
  75.       up any clarification you might have achieved with the commenting.
  76.  
  77.     The major exception to these rules are file headers.  The beginning of
  78. source and header files should always have some descriptive information,
  79. including: file name, author, purpose, modification dates, etc...  These
  80. comment blocks should always have a simple vertical line of unobtrusive
  81. astricks, framed with the required forward slashes.  People using C++ style
  82. commenting in C programs should be drawn and quartered.
  83.  
  84.     The other exception to this rule is when you are writing code specifically
  85. for the benefit of others.  If the code is intended to be a learning tool, 
  86. copious commenting is allowable.
  87.  
  88.     Variable and function nomenclature should have connotation as to what their
  89. purpose in life is.  As short as possible while still preserving some sort of
  90. identity.  Descriptive names are wonderful, but don't go overboard.  Generally,
  91. a condensed one or two word descriptor (possiblely connected via an underscore)
  92. will work fine.  And please, no mixed case.  The only time uppercase characters
  93. should appear in C code are in symbolic constants and macros (and possibly
  94. strings and comments).
  95.  
  96.  
  97.     This tirade is the result of my experiences in reading and writing C code.
  98. In my travels as a stalwart mediocre programmer, I have progressed through many
  99. levels of maturity in my programming style.  Much of my old code exhibits many
  100. of the very things eschewed as anathema in this jeremiad.  Well, what can I
  101. say?  I believe that I have grown.  I am at home with the me.  This is me
  102. breathing.  (Tell me what movie that's from, and I will give you a Phrack
  103. Donut.)
  104.  
  105.  
  106. Enjoy the magazine.  It is by and for the hacking community.  Period.
  107.  
  108.  
  109. -- Editor in Chief ----------------[  route
  110. -- Director of Public Operations --[  dangergirl
  111. -- Phrack World News --------------[  disorder
  112. -- Werdsmith ----------------------[  loadammo
  113. -------- Elite -------------------->  asriel
  114. -- Santa vs. Jesus ----------------[  ISS vs. SNI
  115. -- Festively Plump ----------------[  Cartman
  116. -- Extra Special Thanks -----------[  No one.
  117. -- Official Phrack CD -------------[  FLA/Flavour of the Weak
  118. -- Official Phrack Drink ----------[  `The C Kilborn` (2.9 parts ketel one,
  119. -----------------------------------|  .1 parts tonic)
  120. -- Shout Outs and Thank Yous ------[  Lords of Acid, cantor, Yggdrasil,
  121. -----------------------------------|  snokerash, Voyager, TNO, Jeff Thompson,
  122. -----------------------------------|  angstrom, redragon, Rob Pike, halflife
  123. -- B.A. Baracus Phrack Fracas -----[  loadammo vs. Death Veggie
  124. -- Original flip.c author (props) -[  datagram
  125. -- Gas Face Given (drops) ---------[  solo, klepto
  126.  
  127. Phrack Magazine V. 8, #52, January 26, 1998.  ISSN 1068-1035
  128. Contents Copyright (c) 1998 Phrack Magazine. All Rights Reserved.  Nothing
  129. may be reproduced in whole or in part without written permission from the
  130. editor in chief.  Phrack Magazine is made available quarterly to the public,
  131. free of charge.  Go nuts people.
  132.  
  133.  
  134. Subscription requests, articles, comments, whatever should be directed to:
  135.  
  136.                 phrackedit@phrack.com
  137.  
  138. Submissions to the above email address may be encrypted with the following key:
  139.  
  140. -----BEGIN PGP PUBLIC KEY BLOCK-----
  141. Version: 2.6.2
  142.  
  143. mQENAzMgU6YAAAEH/1/Kc1KrcUIyL5RBEVeD82JM9skWn60HBzy25FvR6QRYF8uW
  144. ibPDuf3ecgGezQHM0/bDuQfxeOXDihqXQNZzXf02RuS/Au0yiILKqGGfqxxP88/O
  145. vgEDrxu4vKpHBMYTE/Gh6u8QtcqfPYkrfFzJADzPEnPI7zw7ACAnXM5F+8+elt2j
  146. 0njg68iA8ms7W5f0AOcRXEXfCznxVTk470JAIsx76+2aPs9mpIFOB2f8u7xPKg+W
  147. DDJ2wTS1vXzPsmsGJt1UypmitKBQYvJrrsLtTQ9FRavflvCpCWKiwCGIngIKt3yG
  148. /v/uQb3qagZ3kiYr3nUJ+ULklSwej+lrReIdqYEABRG0GjxwaHJhY2tlZGl0QGlu
  149. Zm9uZXh1cy5jb20+tA9QaHJhY2sgTWFnYXppbmU=
  150. =1iyt
  151. -----END PGP PUBLIC KEY BLOCK-----
  152.                    
  153. As always, ENCRYPTED SUBSCRIPTION REQUESTS WILL BE IGNORED.  Phrack goes out 
  154. plaintext.  You certainly can subscribe in plaintext.
  155.  
  156. phrack:~# head -20 /usr/include/std-disclaimer.h
  157. /*
  158.  *  All information in Phrack Magazine is, to the best of the ability of the 
  159.  *  editors and contributors, truthful and accurate.  When possible, all facts
  160.  *  are checked, all code is compiled.  However, we are not omniscient (hell,
  161.  *  we don't even get paid).  It is entirely possible something contained 
  162.  *  within this publication is incorrect in some way.  If this is the case, 
  163.  *  please drop us some email so that we can correct it in a future issue.  
  164.  *
  165.  *
  166.  *  Also, keep in mind that Phrack Magazine accepts no responsibility for the
  167.  *  entirely stupid (or illegal) things people may do with the information
  168.  *  contained here-in.  Phrack is a compendium of knowledge, wisdom, wit, and
  169.  *  sass.  We neither advocate, condone nor participate in any sort of illicit 
  170.  *  behavior.  But we will sit back and watch.
  171.  *
  172.  *
  173.  *  Lastly, it bears mentioning that the opinions that may be expressed in the
  174.  *  article of Phrack Magazine are intellectual property of their authors.
  175.  *  These opinions do not necessarily represent those of the Phrack Staff.
  176.  */
  177.  
  178. -------------------------[  T A B L E   O F   C O N T E N T S
  179.  
  180.  1 Introduction                                            Phrack Staff   12K
  181.  2 Phrack Loopback                                         Phrack Staff   60K
  182.  3 Line Noise                                              various        79K 
  183.  4 Phrack Prophile on o0                                   Phrack Staff   07K
  184.  5 Everything a hacker needs to know about getting busted  Agent Steal    72K
  185.  6 Hardening the Linux Kernel                              daemon9        42K
  186.  7 The Linux pingd                                         daemon9        17K
  187.  8 Steganography Thumbprinting                             anonymous      35K
  188.  9 On the Morality of Phreaking                            Phrack Staff   19K
  189. 10 A Quick NT Interrogation Probe                          twitch         18K
  190. 11 Subscriber Loop Carrier                                 voyager        48K
  191. 12 Voice Response Systems                                  voyager        18K
  192. 13 Pay Per View (you don't have to)                        cavalier       19K
  193. 14 The International Crime Syndicate Association           D. Demming     20K
  194. 15 Digital Certificates                                    Yggdrasil      14K
  195. 16 Piercing Firewalls                                      bishnu         31K
  196. 17 Protected mode programming and O/S development          mythrandir     76K
  197. 18 Weakening the Linux Kernel                              plaguez        27K
  198. 19 Phrack World News                                       Disorder       64K
  199. 20 extract.c                                               Phrack Staff   08K
  200.  
  201.                                                                          687K
  202.  
  203. -----------------------------------------------------------------------------
  204.  
  205.     When Sen. Bob Kerrey (D-Neb.) was asked to define encryption, the results 
  206. were horrific.  "Well, I mean, to answer your question, I mean, encryption is 
  207. -- the political equivalent of encryption is you ask me a question, I give you
  208. an answer and you don't understand it," he managed. "I mean, I intentionally 
  209. garble the answer frequently.  I intentionally garble the response so that you 
  210. can't understand what I'm saying.  And that's -- you notice that I've got the
  211. ability to do that." 
  212.  
  213. -----------------------------------------------------------------------------
  214.  
  215. ----[  EOF
  216.